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Abstract 

This report is the technical reference for the T1D4PKT adapter, a communica- 
tion option module for TurboChannel I/O systems. It uses basic HDLC (flags, bit- 
stuffing, CRC) to send and receive packets over a Tl circuit with D4 framing 
(1.544 Mb/s digital telephone circuit). The adapter was designed for use in packet 
switching routers linking local area networks into metropolitan-area and wide-area 
networks. 

This adapter is a research prototype; it is not a product. 
Copyright © 1991 Digital Equipment Corporation 
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1. Overview 

The T1D4PKT adapter is a communication option module for TurboChannel I/O systems. It 
uses basic HDLC (flags, bit-stuffing, CRC) to send and receive packets over a Tl circuit with D4 
framing (1.544 Mb/s digital telephone circuit). The adapter was designed for use in packet 
switching routers linking local area networks into metropolitan-area and wide-area networks. 

The adapter's electrical interface is DSX-1 and its physical interface is an RJ48 modular 
telephone jack. The Data Service Unit (DSU) function is included in the adapter, so it can 
directly connect to a Channel Service Unit (CSU), a multiplexer, etc. 

Figure 1 shows some possible configurations for connecting two packet routers with a Tl cir- 
cuit. The top connection shows a Tl circuit using wire pairs provided by a telephone company; 
the two central offices could be in the same city or on opposite coasts. The middle connection 
shows a Tl circuit multiplexed with three other Tl circuits, perhaps containing voice channels, 
and carried over a microwave radio T2 link; maximum distance is about 15 kilometers between 
radios. The bottom connection shows a Tl circuit multiplexed with twenty-seven other Tl cir- 
cuits and carried over a private fiber optic T3 link. Digital Equipment Corporation owns and 
operates a fiber optic network connecting most company sites in New England. 
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RAD = Microwave Radio 
CSU = Channel Service Unit 
M12 = T1/T2 Multiplexer 
M13 = T1/T3 Multiplexer 



CO = Central Office 
Nl = Network Interface 
LR = Line Repeater 
FR = Fiber Repeater 



Figure 1: Some Possible Configurations 



2. Installation Information 

Figure 2 is a full-scale drawing of the adapter. It is a single-slot TurboChannel option module. 
It uses programmed I/O, not DMA, and occupies 4 MBytes of address space. It is designed to 
operate with a 25 Mhz bus clock; a PAL change is required for systems operating slower than 16 
Mhz. Power consumption is 1.5 Amps at 5 Volts, or 7.5 watts; no 12 Volt power is used. There 
are no jumpers or switches to configure; just plug it in. 
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Two LEDs are visible through a hole next to the modular connector. The Carrier LED lights 
when the adapter is seeing a legal Tl signal. The FrameSync LED lights when the adapter has 
synchronized with the D4 framing pattern imbedded in the Tl bit stream. The LEDs correspond 
to bits by the same name in the control/status register. Both LEDS must be lit for the adapter to 
work. 
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Figure 2: Option Module Layout 

The gross bit rate of a Tl circuit is 1.544 Mb/s, but one out of every 193 bits is overhead, so 
the net bit rate is 1.536 Mb/s. HDLC overhead consumes a few more Kb/s, but the adapter can 
operate with a sustained user data rate in excess of 1.5 Mb/s (the exact rate depends on the data 
pattern; worst case is 1.28 Mb/s for all ones data). A Tl circuit is full duplex: a packet can be 
moving in each direction simultaneously, for an agregate link bit rate of 3 Mb/s (in contrast, an 
Ethernet is half duplex: only one packet can be moving on the Ether at any time, but the bit rate 
is 10 Mb/s). Three T1D4PKT adapters can be plugged into a DS5000/200 system. 
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The application driving the design of this adapter was a router that forwards packets between 
Ethernet local networks. The maximum size of an Ethernet packet is 1518 bytes; The maximum 
packet size of this adapter is 2048 bytes. The limiting factor is the size of FIFO ICs, currently 
4K bytes. Since the capacity of a FIFO chip can grow without changing its pinout, maximum 
packet size can be increased as bigger FIFOs become available simply by loading different ICs. 

Two types of connectors are used on Tl equipment: an 8-pin modular telephone connector 
designated RJ48 by the FCC, and a 15-pin D-series subminiature connector. This adapter uses 
the new RJ48 connector, but it may connect to equipment using the older DA 15 connector. 
Figure 3 shows the corresponding pins in the two connectors. If the other equipment has a 
modular jack, then the cable is wired straight through. A null modem cable connecting two 
nearby adapters with wire and no electronics, turns over the transmit and receive pairs between 
the two connectors. Looking into the cable entry hole on a modular plug with the locking tab 
oriented up, pin one is on the right; DA 15 connectors have pin numbers molded into the plastic 
shell. 
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Figure 3: Connector Pins 

Tl is designed to use twisted wire pairs; a Channel Service Unit, or CSU, can drive one mile 
of 19-gauge wire before a line repeater is required; up to fifty line repeaters can be used, al- 
though three is typical. At the end of a Tl circuit, a telephone company installs a Network 
Interface, or NI, which can be looped back on command from a telco test board. The electrical 
interface of this adapter is called Digital Signal Cross-connect level 1 or DSX-1, a standard sig- 
nal level used between Tl equipment in a telephone central office where distances are limited to 
a few hundred feet [2] [10] [16]. Runs of less than 1 meter can use flat modular cable; length is 
limited because flat modular cable is not shielded and not twisted. Runs from 1 to 10 meters can 
use unshielded twisted pairs such as that used for twisted pair Ethernet. Runs longer than about 
10 meters should use shielded twisted pairs such as that used for token rings. Maximum cable 
length is about 100 meters. Both ends are transformer coupled and the signalling is insensitive to 
polarity, so wires within a pair can be swapped. 
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3. What is Tl? 

Tl was developed at Bell Laboratories in the late 1950s, and the first commercial system was 
installed in 1962 [20] [21] [22] [23]. Urban cable conduits and manholes were filling up and it 
was becoming necessary to carry more than one voice channel on a wire pair. Silicon transistors 
were available, making possible low-power high-reliablility line repeaters. Digital technology 
was maturing; all previous multiplexing schemes used analog technology. 24 analog voice chan- 
nels were converted to 8-bit digital samples 8000 times per second, for a combined data rate of 
1.536 Mb/s. Between each frame of 24 samples (192 bits), an overhead bit was inserted for 
synchronizing terminal equipment at the ends of a circuit, making the total bit rate 1.544 Mb/s. 
Bell System multiplexing schemes traditionally were assigned letter designations, and this first 
digital system was named T-carrier; the electrical format was named DS1, for Digital Signalling 
level 1. A 64 Kb/s voice or data channel is level 0 of the hierarchy; multiplexers combine 
several bit streams from a lower level in the hierarchy to form a higher level bit stream. Figure 4 
summarizes the hierarchy of digital transmission systems that has evolved over the last three 
decades [2] [10] [15]. 
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Figure 4: Digital Hierarchy 

A Tl signal is a sequence of pulses 3 volts high and 324 nanoseconds wide. The presense of a 
pulse in a bit cell represents one data value and the absense of a pulse represents the other binary 
value. Pulses alternate in polarity, making it a 3-level code: +3v, 0 and -3v. This Alternate 
Mark Inversion, or AMI code, has no DC signal component and the highest fundamental fre- 
quency component is half the bit rate. A bit error, changing a pulse into a no-pulse or vise- versa, 
results in two pulses of the same polarity, called a bipolar violation. Figure 5 shows a Tl signal 
with a bipolar violation near the end of the bit string. 
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Figure 5: Tl Waveform 
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Timing information, defining when a receiver should sample the value of a bit, is recovered 
from the pulse stream, so a Tl signal must contain a minimum pulse density. The average pulse 
density must be at least 12.5%, or one pulse in eight bit cells, and there must be no more than 15 
consecutive bit cells in which no pulse is present. Channel Service Units are required to insert 
pulses into a Tl stream if the pulse density is too low. As will be explained below, HDLC bit 
stuffing guarantees that the bit stream produced by this adapter meets the pulse density require- 
ment. 

When equipment can't guarantee meeting the pulse density requirements, a scheme called 
Bipolar with 8 Zero Substitution or B8ZS is used. B8ZS replaces eight consecutive bit cells that 
contain no-pulses with a sequence of pulses containing a distinctive bipolar violation. Normally, 
intermediate equipment in a circuit removes bipolar violations, but when a circuit is ordered with 
the B8ZS feature, these particular bipolar violations are not eliminated and are not counted as 
errors. This adapter never generates long strings of no-pulses so it does not use B8ZS. 

The clock used by a Tl transmitter may come from a local oscillator (local or master timimg), 
or from the received pulse stream (loop or slave timing) [1] [8]. Local oscillators can be as much 
as 75 bits per second fast or slow, so multiplexers must be prepared to handle unsynchronized 
pulse streams. Currently, most point-to-point circuits offered by common carriers go through 
such asynchronous multiplexers and the end-user equipment must provide timing [5] [9] [11]. 
As analog transmission equipment is retired from service and digital VLSI continues to spread, 
carriers are installing a new generation of synchronous multiplexers which require all transmit- 
ters to be frequency-locked to a single timing source provided by the network and recovered 
from the received pulse stream [12] [14]. 

Timing jitter, or short-term variations of the significant instants (when to sample the values of 
bits) from their ideal positions in time, is a big problem for Tl (and token rings and FDDI for 
similar reasons). Line repeaters introduce pattern-dependent jitter [25] and multiplexers intro- 
duce waiting time jitter [24]. Long-term variations, called wander, are caused by such things as 
daily temperature variation in pole-mounted cable which can change the electrical length of a 
circuit by many bits. This adapter includes a wander and jitter attenuator which meets all re- 
quirements for operation while frequency-locked to the received pulse stream [9] [18]. 

The framing bit pattern is the sequence of overhead bits inserted between groups of 24 8-bit 
samples. While twisted pairs and line repeaters do not distinguish frame bits from data bits, 
multiplexers usually require that Tl signals contain a framing pattern. D4, the most common 
framing format and the one implemented by this adapter, consists of the 12-bit repeating se- 
quence 100011011100 [6] [17]. A new framing format called Extended Super Frame or ESF, 
uses some of the frame bits as a checksum over preceding data bits, and other frame bits as a 
low-speed data link for monitoring and controlling equipment in the circuit. There are two com- 
peting standards for how to use the facility data link in ESF: AT&T [7] and BellCore [13] do it 
one way, and ANSI [3] does it a different way; manufacturers offer both versions. 

A continuous stream of pulses without an imbedded framing pattern is generated by trans- 
mission equipment when it is taken out of service for maintenance (such as a loopback test) and 
when a failure is detected that prevents delivery of data. This signal, called blue alarm or all 
ones, is part of a larger failure reporting scheme that has evolved over the years. When a piece 
of transmission equipment loses its upstream signal, it sends blue alarm downstream (since it has 
no real data to send) and it sends yellow alarm upstream. 
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Europe adopted the good ideas from the American digital telephone system, and fixed many of 
its faults. Consequently European Tl, called El, is similar but not compatible. The bit rate is 
2.048 Mb/s, or 32 8-bit samples 8000 times per second. Coax cable is often used rather than 
twisted wire pairs. High Density Bipolar order 3, or HDB3 coding, replaces four consecutive 
no-pulses with a 4-bit sequence containing a bipolar violation, similar to B8ZS. Frame bits are 
not sprinkled in between groups of bytes as in Tl, but rather two time slots, bytes 0 and 16, are 
reserved for synchronization patterns, checksums, and facility data link, similar to ESF. This 
format is called PCM30, because it carries 30 Pulse Code Modulation voice channels. 

There is much more to Tl than has been explained here, but most of it only applies to circuits 
carrying voice channels. The Tl signal generated by this adapter resembles 24 PCM voice chan- 
nels just enough to easily pass through telephone networks. 

4. What is HDLC? 

Synchronous Data Link Control, or SDLC [27] [28], was developed by IBM in the late 1960s 
as an improvement over BiSync [26], an older method for sending packets over a serial link. 
During the 1970s various standards bodies adopted modified versions: the American National 
Standards Institute called their version Advanced Data Communication Control Procedure or 
ADCCP [4]; The International Standards Organization called their version High-Level Data Link 
Control or HDLC [19]. 

The good idea in SDLC is bit stuffing (as opposed to byte stuffing used in BiSync) to distin- 
guish control information from user data. Between packets, an idle transmitter sends continuous 
Flags: (01111110). If the eight bits after a flag are not also a flag, then they are the first eight 
bits of a packet. Within a packet, a transmitter stuffs, or inserts, a 0-bit after five consecutive 
1-bits; a receiver unstuffs, or deletes, a 0-bit after five consecutive 1-bits. Bit stuffing prevents 
data patterns from looking like flags. Six or more consecutive 1-bits terminates a packet. If 
there are exactly six consecutive 1-bits (another flag) then the packet ends normally. If there are 
seven or more 1-bits (an Abort) then the packet is damaged and should be discarded. 

The bytes just before a packet's ending flag are a Cyclic Redundancy Checksum or CRC. The 
CRC is calculated by the transmitter, appended to the end of the data before the flag, and 
checked by the receiver. If the CRC is not correct, the packet is damaged and should be dis- 
carded. The CRC is the remainder after dividing the packet bits by a polynomial. When the 
receiver does the same division on the incoming packet bits including the CRC, the result should 
be zero. 

Bit stuffing can be used to satisfy the pulse density requirements of a Tl circuit by encoding a 
0-bit as a pulse and a 1-bit as a no-pulse. This is called Inverted HDLC because voice channels 
traditionally encode 1-bits as pulses (all ones is more correctly called all pulses). The worst case 
happens when a no-pulse frame bit falls in an HDLC flag, resulting in seven consecutive no- 
pulses, which is 12.5% pulse density. 

There is much more to HDLC than has been explained here, but most of it is not required for 
sending unreliable datagrams. If desired, HDLC's address and control fields can be im- 
plemented by host software. 
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5. What is a TurboChannel? 

A TurboChannel is a synchronous asymmetric input/output bus designed by Digital Equip- 
ment Corporation for use in workstations [29] [30] [31]. It is synchronous because there is a 
global clock whose rising edge is the reference for all bus signals. It is asymmetric because there 
is one system module and some number of option modules connected to it. The system module 
can read and write the option modules, and option modules can read and write the system 
module, but option modules can't talk to each other. 

When a program running in the system module executes a load or store instruction whose 
effective address falls within the address space of an option module, an I/O read or I/O write bus 
transaction is performed. The system module asserts a signal selecting an option module, and 
places an address on the 32-bit address/data bus, which the option module saves in a register. In 
the next cycle the system module reads or writes a word; if the option module is not ready, it can 
assert a signal to stall the transaction. 

For DS5000 systems, I/O reads and writes to the adapter should use addresses in the uncached 
and unmapped KSEG1 memory region (the base address of I/O slot 0 is OxBEOOOOOO and that of 
slot 1 is 0xBE400000). A DS5000/200 can do 5 I/O writes or 2 I/O reads per microsecond. The 
Tl transmitter requires an I/O write and the receiver requires an I/O read about every 5 
microseconds when going full-tilt boogey. 

An option module can read and write main memory via the system module by performing a 
Direct Memory Access or DMA bus transaction. An option module asserts a read or write signal 
to start a DMA operation, and then waits for an acknowledgement from the system module. 
Upon receipt of an ack, the option module drives an address onto the bus and then writes, or after 
a pause, reads 32-bit words on each succeeding cycle, for a peak bandwidth of 100 MBytes/sec 
(one 32-bit word every 40 ns = 800 Mbits/sec = 100 MBytes/sec). At 192 KBytes/sec each way, 
this adapter does not use DMA. 

The TurboChannel clock can be any fixed frequency between 12.5 and 25 MHz. For slow 
TurboChannels, the IOCTL2 PAL at position E14 must be changed. The fast PAL works from 
27 MHz to 15.6 MHz (DS5000/200); the slow PAL works from 16.6 MHz to 7.8 MHz 
(DS5000/lxx). This will be fixed somehow in the next artwork revision. 

There is nothing more to the TurboChannel; it is refreshingly simple. Many of DEC's I/O 
buses are asynchronous and symmetric, making them slow and complex, and raising the cost to 
implement simple devices. 

6. Programming Interface 

The T1D4PKT adapter is a programed I/O device; it does not use DMA. A device driver 
communicates with the adapter by executing load and store instructions whose effective ad- 
dresses are within the adapter's 4 MByte address space. 

There are three regions in the adapter address space: control/status, data, and option rom. 

• The Control/Status Register (CSR) is a single address. Some of the bits in this 
register are read-only, such as FIFO status, and some are read/write, such as inter- 
rupt enable and loopback. 
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• The Data Register is a single address to which transmitter bytes are written and 
from which receiver bytes are read. Even though the transmitter and receiver are 
completely independent of each other, their data registers share the same I/O ad- 
dress. 

• The Option ROM occupies 128K addresses in the adapter's space. It contains infor- 
mation about the adapter (type, manufacturer, revision level, etc) and diagnostic 
programs that can be loaded into memory and executed under the ROM Executive. 

6.1. Control/Status Register 

The control/status register, figure 6, is addressed when the adapter is selected and address bits 
17 and 4 are one. Other address bits are ignored, so there are many other I/O addresses which 
will also reference the CSR. 

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 

+ + + + + + + + + + + + + + + + + 

! RX I RX | RX | XX 1 TX [ TX | TX | TX I RX I RX | TX | | TX | TX | RX | 

| Fif o | Fif o I Fif o | xx | Fif o | Fif o | Fif o I Strt I Carr | Frm | Undr | Loop I Lcl Int lint Int I 
I Full | Half | Empt | xx | Full | Half | Empt | | ier | Sync I Flow | Back | Clk Req I Req Enbl I 

Bits 31.. 16: no connection 

Bit 15 - Rx Fifo Full; read-only; cleared by hardware reset. 

One if the Receiver FIFO is full (4096 bytes) . 
Bit 14 - Rx Fifo Half; read-only; cleared by hardware reset. 

One if the Receiver FIFO is more than half full (2049-4096 bytes) . 
Bit 13 - Rx Fifo Empty; read-only; set by hardware reset. 

One if the Receiver FIFO is empty. 
Bit 12 - no connection. 

Bit 11 - Tx Fifo Full; read-only; cleared by hardware reset. 

One if the Transmitter FIFO is full (4096 bytes) . 
Bit 10 - Tx Fifo Half; read-only; cleared by hardware reset. 

One if the Transmitter FIFO is more than half full (2049-4096 bytes) . 
Bit 9 - Tx Fifo Empty; read-only; set by hardware reset. 

One if the Transmitter FIFO is empty. 
Bit 8 - Tx Start; read-write; cleared by hardware reset. 

Set by a write to the Data register or CSR with bit 8 on. 

Cleared by the Transmitter when it starts sending a packet. 
Bit 7 - Rx Carrier; read-only; unaffected by hardware reset. 

One if the receiver sees a legal Tl signal. 

If this bit is off then no packets will be received. 
Bit 6 - Rx Frame Sync; read-only; unaffected by hardware reset. 

One if the receiver is locked onto the D4 framing pattern. 

If this bit is off then no packets will be received. 
Bit 5 - Tx UnderFlow; read-write; cleared by hardware reset. 

Set by hardware if the transmitter needs a byte but the FIFO is empty. 

Cleared by software writing the CSR with a one bit in this position. 
Bit 4 - Loopback; read-write; cleared by hardware reset. 

One if the transmitter output should be looped into the receiver. 
Bit 3 - Tx Local Clock; read-write; set by hardware reset. 

One if the transmitter should use the on-board oscillator. 

Zero if the transmitter should use the receiver clock. 
Bit 2 - Tx Interrupt Request; read-write; cleared by hardware reset. 

Set by hardware after the last bit of a packet has been transmitted. 

Cleared by software writing the CSR with a one bit in this position. 
Bit 1 - Rx Interrupt Request; read-write; cleared by hardware reset. 

Set by hardware after writing receiver status into the FIFO. 

Cleared by software writing the CSR with a one bit in this position. 
Bit 0 - Interrupt Enable; read-write; cleared by hardware reset. 

Set by software to permit the adapter to cause interrupts. 

Figure 6: Control/Status Register (CSR) 
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csr . TxIntReq, csr . RxIntReq, and csr . TxUnderf low are set by hardware and 
cleared by software. Since any of these bits can be set at any time, clearing them must be done 
with care. To clear one of these bits, write the CSR with a one in the bit position to be cleared; 
be careful not to change any other bits such as csr.IntEnbl, csr . LoopBack, and 
csr . TxLclClk. 

The adapter can be operated without interrupts by clearing csr.IntEnbl and polling 
csr . RxIntReq and csr . TxIntReq. In addition to the Interrupt Enable bit in the adapter 
CSR, a bit in a CPU register must be set for interrupts to occur, csr. TxIntReq and 
csr . RxIntReq must both be cleared before returning from an interrupt or else another inter- 
rupt will immediately happen. 

csr . TxUnderf low is the only transmitter status bit. Transmitter FIFO underflow means 
the hardware and software are seriously out of sync. The packet being transmitted is terminated 
by an HDLC abort with no CRC, insuring that the receiver will notice that it is damaged. 

Nearly all of the adapter can be tested by setting csr . LoopBack and verifying that every 
packet transmitted is also received. The receiver ignores data from the Tl circuit when looped 
back, so any packets sent by the far end will be lost. If packets were transmitted on the Tl 
circuit as well as being looped into the near-end receiver, the far-end receiver might think that 
the loopback test packets were real data that it should act on. Therefore, the transmitter sends 
unframed all-ones onto the Tl line when in loopback. All-ones keeps the equipment in the cir- 
cuit happy but because it doesn't contain the framing pattern, the receiver at the far end will 
consider the circuit down (csr . Frame Sync will be false). 

The proper value for csr. TxLclClk depends on properties of the particular Tl circuit to 
which the adapter is connected. Some circuits require that the transmitter use the clock 
recovered by the receiver from the incoming data (TxLclClk=0). Other circuits require the 
transmitter to supply its own locally generated clock (TxLclClk=l). When the circuit 
provides the clock, the adapters at both ends must set TxLclClk=0; when the circuit does not 
provide the clock, at least one of the adapters must set TxLclClk=l (preferably both). Fine 
point: the transmitter uses the on-board oscillator regardless of the state of csr . TxLclClk if 
csr . LoopBack is true or csr . Carrier is false. 

6.2. Receiver Data Register 

The receiver data register, figure 7, is the read-port of a 4K by 9-bit FIFO. On the Tl line side 
of the FIFO, incoming data bits are shifted into an 8-bit register and then written in parallel into 
the write-port of the FIFO (see figure 11). One byte of receiver status, figure 8, is written into 
the FIFO after the last data byte of a packet. This receiver status byte is distinguished from the 
data bytes by the ninth bit of the FIFO, which appears as RxData . PktEnd. If PktEnd is 
zero, then bits 7..0 are a data byte, otherwise they are the receiver status applying to the 
previously read data bytes. The last four bytes before the receiver status are the packet's CRC, 
and they should be discarded by software. 

Software must protect itself from very long packets. There is no inherent limit on packet 
length imposed by the hardware, and even if a transmitter never sends very long packets, they 
can occur at the receiver during initialization, or because of slow service by the device driver, or 
because of data errors on the Tl line. 
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15 14 13 12 11 10 9 8 7 0 

I RX ! RX | RX I xx | TX | TX | TX | End | I 
| Fifo | Fifo | Fifo | xx | Fif o | Fif o | Fif o | of | Data or CRC Byte | 

| Full | Half | Empt | xx | Full | Half | Empt | Pkt | I 

Bits 31.. 16: no connection 

Bits 15.. 9: Rx and Tx FIFO status 

See the description in Control/Status Register. 
Bit 8 - End of Packet 

One if bits 7..0 is Ending Status 

Zero if bits 7. .0 is a Data byte. 
Bits 7..0: Data or CRC Byte 

A data byte; the last four bytes before End Of Pkt are CRC bytes. 

Figure 7: Receiver Data Register (RxData) 

During operating system initialization, the device driver must synchronize with the adapter. 
The receiver runs all the time, and attempts to write packet bytes into the FIFO even if software 
isn't servicing the adapter. When a device driver first starts up, it is likely to find that the 
receiver FIFO has overflowed and is full of stale packet fragments. These bogus fragments must 
be flushed until the FIFO is empty and a good receiver status has been read. 

Efficient transfer of data from the receiver to main memory depends on minimizing I/O read 
references to the adapter, which take 10 cycles. Ideally the ratio of I/O reads to data bytes 
moved is slightly greater than one but much less than two. The FIFO status bits in the receiver 
data register reflect the state of the FIFO including the effect of the current read operation. If 
RxData . Fif oEmpty, is true then bits 7..0 are the last data byte available at the instant the 
read was happening, and the FIFO status bits in the CSR should be checked before reading the 
data register again. Do not read the receiver data register when csr . RxFif oEmpty is true. 

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 

+ + + + + + + + + + + + + + + + + 

I RX [ RX | RX | xx | TX ! TX | TX | End I Loss I Loss I Loss | | | I Fifo | 

| Fif o | Fif o | Fif o | xx | Fif o | Fif o | Fif o | of | of | of I of 0 I 0 Abrt I Over | Bad I 
I Full | Half | Empt | xx | Full | Half | Empt | Pkt | Sgnl | Fram | Data | | I Flow | CRC I 

Bits 31.. 16: no connection 

Bits 15.. 9: Rx and Tx FIFO status 

See the description in Control/Status Register. 
Bit 8 - End of Packet 

One if bits 7..0 is Ending Status. 

Zero if bits 7..0 is a Data byte. 
Bit 7 - Loss of Signal 

Zero if the receiver sees a legal Tl signal. 
Bit 6 - Loss of Frame 

Zero if the receiver is locked to D4 framing pattern. 
Bit 5 - Loss of Data 

Zero if the packet is a multiple of eight bits; one if bits lost/added. 
Bit 4 - zero 
Bit 3 - zero 
Bit 2 - Abort 

One if the packet ended in an HDLC abort. 
Bit 1 - FIFO Overflow 

One if the receiver wanted to write a byte but the FIFO was full. 
Bit 0 - Bad CRC 

One if the Cyclic Redundancy Checksum is not correct. 



Figure 8: Receiver Status (RxStatus) 
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The correct receiver status for a packet is bits 7..0 all zeros: 

• LossOf Signal is one if the Tl signal did not contain sufficient pulses to keep the 
clock recovery circuit functioning. If no pulse is received in 32 consecutive bit cells 
then LossOfSignal goes to one, terminating any packet in progress. 

• LossOf Frame is one if the Tl signal did not contain the D4 framing pattern. The 
frame detector will tolerate up to two incorrect bits out of 12 consecutive frame bits. 
If the receiver loses the framing pattern then LossOf Frame goes to one, terminat- 
ing any packet in progress. 

• LossOf Data is one if the number of bits between HDLC flags, after deleting 
stuffed bits, was not evenly divisible by eight. If the remainder is non-zero then bits 
have been added or dropped from the data stream. 

• Abort is one if a packet ended with an HDLC abort. Packets normally begin and 
end with HDLC flags, (01111110). If the Tl circuit dies (no more pulses), then the 
receiver will see all ones, which is an HDLC abort. 

• Fif oOverf low is one if the receiver wanted to write the FIFO, but it was full. 
The data is lost, but the occurance of the error is remembered as a receiver status bit. 
Fif oOverf low is cleared after successfully writing a receiver status (including 
the Fif oOverf low error bit) into the FIFO. 

• BadCRC is one if the Cyclic Redundancy Checksum on the packet was incorrect. 
The last four bytes of a packet are a 32-bit CRC appended by the transmitter. If a bit 
is inverted, added or dropped between transmitter and receiver then the CRC will be 
bad at the receiver with very high probability. 

6.3. Transmitter Data Register 

The transmitter data register, figure 9, is the write-port of a 4K by 9-bit FIFO. On the Tl line 
side of the FIFO, data bytes are read from the read-port of the FIFO and loaded into a shift 
register (see figure 13). The last byte of a transmitter packet is indicated by setting 
TxData . EndOf Pkt, which becomes the ninth bit in the FIFO. When this byte comes out the 
other end of the FIFO, the transmitter appends the checksum and generates the ending HDLC 
flag. 

Note that a receiver packet ends with a status byte with the ninth bit set, but a transmitter 
packet ends with a data byte with the ninth bit set. The transmitter hardware generates and 
appends the CRC without software help, and the receiver hardware checks but does not delete 
the CRC, which the software must do. 

If TxStart is one, the transmitter stops sending flags and starts reading and sending bytes 
from the FIFO. TxStart is asserted by setting TxData . EndOf Pkt or csr . TxStart. The 
transmitter hardware clears TxStart within 8 bit times, or about 5 microseconds. If TxStart 
is one but the FIFO is empty, then the transmitter simply clears TxStart and continues to send 
flags. 

To transmit a packet, software writes a sequence of bytes into the FIFO through the trans- 
mitter data register. Writing the last byte of the packet (with bit 8 one) sets TxStart which 
starts the transmitter. When the transmitter reads the last packet byte from the FIFO, (the byte 
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31 



9 



8 



7 



0 



+ 



+ + 

I End I 
I of I 
IPkt | 



+ 



unused 



Data Byte 



+ 



+ + 



+ 



Bits 31.. 9: no connection 
Bit 8 - End of Packet 

One if bits 7..0 are the last byte of a transmitter packet. 

Zero if bits 7..0 are a data byte except the last. 
Bits 7 . . 0 : Data Byte 

A data byte. 



with bit 8 set) it appends 4 bytes of CRC, sets csr . TxIntReq and finally goes idle sending 
HDLC flags. 

It is not possible to send back-to-back packets using the simple strategy of writing one packet 
into the FIFO and then waiting for the transmitter to interrupt. The transmitter will be idle for 
the time it takes to service the interrupt and load the next packet into the FIFO. To send back- to- 
back packets, software must write the next packet into the FIFO while the transmitter reads the 
current packet out of the FIFO. 

Using the FIFO to double-buffer packets means that a pair of packets must fit into the 4 Kbyte 
FIFO. If no packet is longer than 2 Kbytes then this strategy works. The software writes the 
first packet into the FIFO, then waits for csr . TxS tart to go false, then writes the next packet 
into the FIFO, and so on. Software may only write one extra packet into the FIFO, even if more 
packets would fit, because TxS tart is a single bit and not a counter. 

Efficient transfer of data from main memory to the transmitter depends on minimizing I/O 
references to the adapter. Ideally the ratio of I/O writes to data bytes moved is slightly greater 
than one but much less than two. Do not write the transmitter data register when 
csr . TxFif oFull is true. If the double-buffered strategy is used then the FIFO status bits 
don't have to be checked in the data transfer loop. 

csr . TxUnderf low is set if the transmitter attempts to read a byte from the FIFO but the 
FIFO is empty. The transmitter sends an HDLC abort without sending a CRC and then goes idle 
sending flags. This should never happen because the transmitter is never started until an entire 
packet is in the FIFO, but sometimes cosmic rays do funny things. 

If the transmitter gets "stuck" in idle with bytes in the FIFO, software can unstick it by setting 
csr.txStart. This wakes up the transmitter without writing any more bytes into the FIFO 
and causes it to read from the FIFO. This must be repeated until the FIFO runs dry. In any case, 
some packet fragments will be transmitted. 

6.4. Option ROM 

The 32 KByte Option ROM occupies the lowest 128 KBytes of adapter address space. The 
Option ROM is addressed when the adapter is selected and address bit 17 is zero. Address bits 
21.. 18 are ignored so there are many other I/O address ranges which also reference the ROM. 
Address bits 16. .2 select a location in the ROM. Address bits 1..0 are ignored because I/O 



Figure 9: Transmitter Data Register (TxData) 
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references are to 32-bit words. Consecutive ROM bytes are the least significant bytes of con- 
secutive 32-bit words. 

The Option ROM has two parts: fixed-format configuration information and variable-format 
objects such as scripts, and executable code. System module firmware called the ROM 
Executive, or REX, can interpret the script objects and execute the code objects. Rather than 
reprogramming a ROM for each new version during development, REX can be directed to read 
an Option ROM image from an Ethernet boot server rather than from the ROM on the Option 
module. A Unix program written in Modula-2 generates the PROM programmer file and the 
net-bootable file. 

REX loads a code object at a fixed address in memory and transfers control to it, passing a 
callback vector, an array of utility procedures that the code object can use to print messages on 
the console, etc. There is only one code object in this adapter's Option ROM, a keyboard-driven 
diagnostic program written in Modula-2. The program is loaded in the cached kernel memory 
region because it runs about four times faster than uncached. 

To use an Option ROM image booted from the net rather than the ROM on the adapter, 
register the file with a boot server, and use the undocumented REX command boot -D n 
6/mop, where n is the slot number of the adapter whose ROM is to be replaced (6/tf tp works 
too). REX commands invoking code objects will read this image rather than the adapter ROM 
until REX is reinitialized. 

7. Diagnostic Program 

The diagnostic program is started by typing t n to the REX prompt of >>, where n is the 
TurboChannel slot number of the adapter to be tested; i.e. t 0 starts the diagnostic program of 
an adapter in slot zero. 

7.1. Program Variables 

There are five program variables which can be set by command and influence the behavior of 
other commands: 

• Length is a cardinal in the range 2. .2048. If the Random program variable (see 
below) is true, then transmitted packets have random lengths between two and 
Length bytes, otherwise transmitted packets have a constant length of Length 
bytes. 

• Random is a boolean variable. If true, then transmitted packets have random 
lengths and are filled with pseudo random numbers, otherwise packets have constant 
lengths equal to txLength and are filled with the constant pattern (0 1...255). 

• DataCheck is a boolean variable. If it is true, then received packets will be 
checked for the proper data pattern and discrepancies printed. If the first four bytes 
of a packet are (0 12 3), then the data pattern in the packet is assumed to be the 
constant pattern (0 1...255), otherwise the first four bytes are assumed to be the in- 
itial value of a pseudo random number generator which is used to check the remain- 
ing data bytes. 
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• LoopBack is a boolean variable. This value is loaded into csr . LoopBack 
whenever the CSR is written. If true, the transmitter output is looped into the 
receiver input, all ones is transmitted to the Tl line, and packets arriving from the 
Tl line are ignored. 

• Clock is a boolean variable. This value is loaded into csr . txLclClk whenever 
the CSR is written. If true, the transmitter uses a local crystal oscillator, otherwise it 
uses the clock recovered from the received signal. 

7.2. Diagnostic Commands 

The diagnostic is a keyboard-driven program which is used to debug adapters and test Tl 
circuits without the complication of going through an operating system. Typing "?" lists all of 
the commands; typing "help" prints a list of the commands along with one-line descriptions. To 
invoke a command, type an unambiguous initial substring terminated by a carriage return or 
space. To stop a running command, type any character. 

• The Quit and Exit commands leave the adapter diagnostic program and return to the 
ROM Executive. 

• The Test command transmits and receives packets continuously. Test is terminated 
by typing any character. For every 10 good packets received, a "!" is printed. Bad 
transmit and receive status values are printed and counted. At the end of the test, the 
number of good and bad transmit and receive packets is printed. This command is 
simply TxTest and RxTest (see below) called in a loop. 

• The TxTest command transmits packets continuously. TxTest is teminated by 
typing any character. For every 10 good packets transmitted, a "!" is printed. If 
csr . txUnderFlow is true, the CSR is printed and the packet is counted as bad. 
At the end of the test, the number of good and bad packets is printed. Packet length 
and contents are controlled by the Length and Random program variables. 

• The RxTest command receives packets continuously. RxTest is terminated by 
typing any character. For every 10 good packets received, a "!" is printed. If any 
error bits are set, the receiver status is printed and the packet is counted as bad. At 
the end of the test, the number of good and bad packets is printed. Packet contents 
are checked if the DataCheck program variable is true. 

• The Echo command transmits any packets received. Echo is terminated by typing 
any character. For every 10 good packets echoed, a "!" is printed. Bad transmit and 
receive status values are printed. At the end of the test, the number of packets 
echoed is printed. 

• The Watch command prints all packets received. Watch is terminated by typing any 
character. Each packet begins on a new line preceded by "data=". Packet data bytes 
are printed as two character hex values separated by spaces. Each packet ends by 
printing the receiver status on a new line. 

• The Reset command attempts to put the adapter in an idle state. It clears 
csr . rxIntReq, csr . txIntReq, and csr . txUnderf low. It sets 
csr. LoopBack and csr.txLclClk to the current value of the program vari- 
ables of the same name. It flushes the transmitter and receiver FIFOs. Remember 
that the receiver runs continuously and will put any packet that arrives into the 



14 



TurboChannel Tl Adapter 



RxFIFO, so if csr . LoopBack is false and packets are arriving, the status after a 
reset may still show csr . rxIntReq true and csr . rxFif oEmpty false. 

• The Status command prints the contents of the Control/Status Register (CSR) as a 
hex number and as named fields. 

• The Length command sets the Length program variable. Acceptable values are 
between 2 and 2048. 

• The Random command toggles the Random program variable. Transmitted packets 
are random length and filled with random data if Random is true. 

•The DataCheck command toggles the DataCheck program variable. Data in 
received packets are checked if DataCheck is true. 

• The Loop command toggles the LoopBack program variable. Transmitter output 
is looped to receiver input if LoopBack is true. FrameSync and Carrier LEDs 
should light when LoopBack is set. 

• The Clock command toggles the Clock program variable. The transmitter uses the 
local crystal oscillator if Clock is true. 

• The Speed command transmits back-to-back packets and measures bits per second 
and packets per second. Speed is terminated by typing any character. The length of 
the transmitted packets is controlled by the Length program variable. The data in 
the transmitted packets is the constant pattern (0 1...255). This data pattern will 
cause HDLC bit-stuffing to occur, so the bit/sec reported by the command will be 
somewhat less than the maximum rate of 1.536 Mb/s. Five overhead bytes are 
added to each packet when calculating the bit rate (one flag and four CRC bytes). 
The clock used for this test has a resolution of 1 second, so the accuracy increases 
with increasing test time. The speed test is a tight loop running on the bare 
hardware; your mileage may vary when running the adaptor through an operating 
system. 

• The AbortTest command tests the HDLC abort generation and detection logic in the 
transmitter and receiver. AbortTest is terminated by typing any character. At the 
end of the test the number of good and bad results is printed. The transmitter is 
forced to generate an HDLC abort by deliberately causing a transmitter FIFO under- 
flow: two bytes are written into the FIFO and then the transmitter is started by set- 
ting csr.txStart instead of setting the ninth bit of the last data byte. If 
RxStatus . abort is true, then everything is working. 

• The ScopeLoop command continuously reads the control and status register. 
ScopeLoop is terminated by typing any character. This command generates steady 
oscilloscope pictures for debugging the TurboChannel control logic. 

7.3. Using the Commands 

By looping a Tl circuit at various points and using the diagnostic commands, a number of 
questions about the link and adapters can be answered. 

• Does-the-Adapter-Work Test. A quick and thorough way to test the adapter is to set 
LoopBack and run the Test command. This tests the entire adapter except for the 
modular jack, transformers, and driver/receiver circuits. If none of the program 
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variables have been changed from their initial values, Test will transmit packets of 
randomly varying length filled with random numbers and check the data in the 
returning packets. At the beginning of the test, a few bad statuses may be reported 
as the software synchronizes with the hardware. At the end of the test, the number 
of good packets received may not exactly match the number of good packets sent. 

• Does-the-Tl-Circuit-Work Test. Rather than looping the adapter internally, there 
are usually several ways to loop the Tl circuit itself. Once the circuit has been 
looped externally, Test can be run without setting csr . LoopBack. Setting the 
loopback switch on the CSU will test all of the adapter, the cable from the adapter to 
the CSU, and most of the CSU. CSUs also usually have a switch which will send a 
special signal down the Tl circuit and loop the far-end CSU. Doing this will test all 
of the adapter, near-end CSU, Tl circuit, and most of the far-end CSU. 

• Two-Way Test. To test both adapters and the entire Tl circuit, run the Echo com- 
mand on one adapter and run Test on the other adapter. In this case 
csr . LoopBack should be false at both adapters. 

• One-Way Test. If Test fails, it isn't always obvious whether the receiver or the 
transmitter is having problems. These can be tested separately by using a known- 
good adapter. Connect the two adapters with a null-modem cable, run RxTest on the 
good adapter and run TxTest on bad adapter. If the test fails, the problem is a bad 
transmitter. Similarly, run TxTest on the good adapter and RxTest on the bad adapt- 
er. If the test fails, the problem is a bad receiver. This technique can also be used to 
isolate a failure in one direction of a Tl circuit. 

• Is-Anybody-Out-There Test. Often when installing a new Tl circuit, it is useful to 
know if any packet is being received. Also, when debugging new operating system 
software, it is sometimes useful to get an indendent opinion on whether packets are 
being transmitted and if they are well-formed. The Watch command will print out 
anything that is not an HDLC flag, including line noise, test patterns generated by 
the telephone company, and malformed packets. 

8. Technical Description 

The Line Interface Unit, or LIU, contains analog black magic: delay-line clock recovery, a 
jitter attenuator, and an output pulse shaper. The LIU recovers the clock from the incoming 
pulse stream with a digital phase locked loop containing a 13-tap variable delay line. Jitter in 
the recovered clock is attenuated by means of a 32-bit FIFO and a variable crystal oscillator. 
Output pulses are formed by a slew-rate controlled fast digital-to-analog converter generating a 
piecewise linear approximation of a wire-length dependent pulse shape. 

The Transmitter and Receiver Finite State Machines (TxFSM and RxFSM), use 8Kx8 regis- 
tered PROMs. The RxFSM has eight states and 21 outputs, and the TxFSM has seven states and 
23 outputs; each machine uses three PROMs. The FSMs clock about eight times per Tl bit cell; 
a Tl bit is 648 ns wide and the FSMs clock every 80 ns. This gives plenty of cycles between 
each bit during which to shift shift registers, count counters, test for underflow, etc. 1.5 Mb/s is 
loafing: things can be done by brute force in TTL without pushing any speed limits. 

The programmed I/O interface to the device driver requires only seven ICs. The 4KB FIFOs 
greatly ease the interrupt latency requirements on the operating system and make it possible to 
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handle several packets during one interrupt context switch when the adapter is busy. They also 
make it easy to handle back-to-back packets (separated by only one HDLC flag) without heoric 
efforts by the device driver. Careful thought was given to minimizing the number of instruction 
cycles per byte transferred. By returning the receiver FIFO status when a data byte is read, an 
extra I/O read of the CSR is avoided inside the copy loop; similarly, an extra I/O read of the CSR 
is not necessary in the transmitter copy loop. 



8.1. Data Path 

Figure 10 is a block diagram of the data paths in the adapter. Starting at the Tl line, pulses are 
coupled through a transformer into the LIU. The LIU derives a clock from the incoming pulses 
and supplies data bits to the RxFSM. The RxFSM deletes the Tl frame bits and the HDLC stuff 
bits and accumulates the data bits in a Shift Register, SR. When the SR is full, the RxFSM 
writes the data byte into the FIFO; it can also parallel load the SR with receiver status and write 
that into the FIFO. Data bytes flow out of the FIFO, through the I/O Interface and onto the 
TurboChannel when a program executes a load instruction whose effective address falls within 
the adapter' s 4 MByte space. 
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Figure 10: Data Paths in the Adapter 

The data path for the transmitter is symmetric with the receiver. Data bytes flow over the 
TurboChannel, through the I/O interface and into the FIFO when a program executes a store 
instruction whose effective address falls within the adapater's address space. The TxFSM reads 
bytes from the FIFO loads them into the SR, inserts Tl frame bits, HDLC stuff bits and CRC 
bits, and feeds the resulting bit stream to the LIU. The LIU generates the positive and negative 
pulses and drives the DSX- 1 interface through a transformer. 



8.2. Receiver 

Figure 11 is a block diagram of the receiver; arrows show the path of the data bits. The LIU 
supplies three signals to the RxFSM through synchronizers: clock, data and loss-of-signal. The 
RxFSM shifts data bits into 8SR, counting the bits using 8Cnt. When 8Cnt underflows, the byte 
in 8SR is written into the FIFO; status is also loaded into 8SR and written into the FIFO. As bits 
shift out of 8SR, they shift in to the CRC; the ending HDLC flag pushes the last data byte into 
the CRC. HDLC stuff bits are detected by counting consecutive no-pulses using 5Cnt\ HDLC 
flags are recognized by a 3-state FSM attached to it. 
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Figure 11: Block Diagram of the Receiver 

Tl frame synchronization uses 12SR, 192Cnt, and FrameRom; the object is to make 192Cnt 
underflow when a frame bit is expected. 8Cnt and 5Cnt are also used since data bytes are not 
accumulated and stuff bits are not deleted while trying to locate the framing pattern. The first 
step is to zero 12SR and preset 192Cnt, 8Cnt and 5Cnt; the next bit to emerge from the LIU is 
tentatively assumed to be a frame bit and it is shifted into 12SR. The FrameRom looks at 12SR 
and renders a judgement as to whether it contains the framing pattern (100011011100) in one of 
its 12 rotations: 

• No. 12SR does not contain anything remotely like a framing pattern. 

• Maybe. 12SR contains a framing pattern up to the last 1-bit (recall that 12SR is 
initialized to 0s and less than 12 frame bits may be in the register). 

• Error. 12SR contains a framing pattern with one or two bits in error. 

• Yes. 12SR contains a framing pattern exactly. 

If after shifting a potential frame bit into 12SR, FrameRom says No or Error then move over 
one bit in the stream and assume that it is a frame bit by going back to step one. As long as 
FrameRom says Maybe or Yes, continue shifting every 193rd bit into 12SR, and counting 8Cnt 
and 5Cnt; when they both underflow, 40 good frame bits have been seen so csr . FrameSync 
is set. In the worst case, frame synchronization takes (192*193*40) bits, or about one second, 
typically it takes about 100 ms. D4 framing requires tolerance of up to three bits out of 12 in 
error without losing frame sync, so once csr . FrameSync is set, only No from the FrameRom 
initiates reframing; but while frame sync is being attempted, no errors are tolerated. Figure 12 
shows the tradeoff between Error and No judgements from the FrameRom as the number of bad 
frame bits is varied. Requiring 40 good frame bits to aquire sync and losing sync if more than 
two bits are bad is much more stringent than D4 requires, but voice is quite tolerant of errors and 
reframing disconnects calls. 
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Figure 12: Loss-of-frame lock threshold 



8.3. Transmitter 

Figure 13 is a block diagram of the transmitter; arrows show the path of the data bits. Note 
how similar it is to the receiver; the major difference is that less machinery is needed to transmit 
the frame pattern than to receive it. The Mux generates the framing pattern from a modulo- 12 
counter, as well as steering data, CRC and stuff bits to the LIU. Mux feeds back the value of the 
outgoing bit to TxFSM so that it can count bits for HDLC stuffing. The signal from LIU to 
TxFSM is the transmitter clock, informing it that a bit has been accepted and the next bit should 
be set up. The signal from the FIFO to the RxFSM is fifoEmpty; the signal from 8SR is En- 
dOfPkt (ninth fifo bit). 
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Figure 13: Block Diagram of the Transmitter 
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9. Design Choices 

Why use Crystal Semi's LIU? At least thirteen companies make Line Interface Unit ICs; 
some just second- source others, some make separate receiver and transmitter chips, and some 
partition functions in odd ways. Figure 14 compares the nine LIU chips that looked promising. 
Tech = chip technology; RCIk = Receiver clock recovery technique; Comp = external com- 
ponents; LOS = reports loss of signal; Loop = loopback capability; BPV = reports bipolar viola- 
tions; Puis = transmitter pulse shaping; Jitt = attenuates jitter. 
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Figure 14: Line Interface Unit ICs 

Jitter attenuation was the deciding factor in choosing an LIU. When the transmitter clock is 
derived from the received pulse stream, jitter must be eliminated or it may build up to unaccept- 
able levels by the time it gets back to the far end. The Rockwell chip was new and only avail- 
able for sampling, and its input jitter tolerance was half that of the Crystal chip; the Dallas chip 
was a receiver only (but nicely done). The Tl and Exar chips were rather old designs requiring 
many external components; the Silicon Systems chip required fewer components. The Mostek 
and Siemans chips were European designs using oversampling digital phase locked loops and no 
external components except crystals; both of them looked very good and would have been con- 
tenders if they had contained jitter attenuators. The AT&T chip was designed by the people who 
invented Tl, but they didn't include a jitter attenuator. (In defense of LIUs without jitter at- 
tenuation, it is often done elsewhere in a design.) The Crystal Semiconductor LIU did every- 
thing required and only a few things not required (output driver monitoring and serial control 
interface). 

Why use through-hole components rather than surface mount? The adapter uses UV- 
erasable and reprogrammable ROMs and PALs in socketed dual-inline packages, permitting cus- 
tom design and easy modification of shift registers, counters, FSMs and random logic. Sockets 
for surface mount and dual-inline packages occupy about the same board area, but dual-inline 
sockets are more reliable and through-hole printed circuit boards are easier to make and modify. 
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Rather than doing extensive simulation before making the printed circuit board, the adapter was 
designed to be easy to modify by reprogramming the ROMs and PALs; every reprogrammable 
part was changed at least once during debugging and two wires were added to unused inputs. 
The added wires were the result of misunderstanding the operation of two ICs, so the behavioral 
models would have been wrong and the errors would not have been caught during simulation. 
The receiver frame sync algorithm was simulated, and it helped, but several changes were neces- 
sary when a real T1D4 signal was seen for the first time. Experience using the adapter suggested 
several changes to the software interface, which were easy to make by reprogramming. A 
programmable gate array, such as those made by Xilinx, is an attractive alternative to partition- 
ing the design among a number of smaller chips. 

Why include the DSU function rather than using an external DSU/CSU? Integrating the 
DSU with the HDLC logic resulted in a very compact design. An external DSU implies an 
electrical interface, such as EIA422/423/449 or V.35, between the HDLC logic and the DSU, and 
the ability to run at fractional Tl speeds. While designing a general-purpose synchronous serial 
adapter is a worthy goal, the goal here was to build a single-purpose Tl adapter. Multiprotocol 
routers exist and the cost of Tl circuits is plummeting, so the need to split a Tl circuit between 
two routers implementing different protocols, or to save money with a fractional Tl circuit will 
fade. Integrating the CSU function into the adapter would have been going too far; a CSU's 
interface is not as flexible as DSX-1. 

Why implement framing rather than using aframer chip? Designing the frame recognizer 
was an intellectual challenge. Several companies make VLSI chips that do D4 and ESF framing, 
plus many features for treating a Tl circuit as 24 voice channels. Other than framing, these 
features are not needed, are sometimes hard to disable, and are always complicated to configure. 
Getting bits past these features without mangling is like walking through a mine field. 

Why D4 framing rather than ESF? ESF is very complicated; D4 is much simpler to imple- 
ment. Most Tl circuits use D4 framing; a circuit with ESF (and usually B8ZS also) is a special- 
order item not available everywhere. If ESF is absolutely required for some reason, then there 
are CSUs which can speak D4 on the customer side and ESF on the telco side; an EIA232 ter- 
minal port on the CSU gives access to the ESF features. 

Why implement HDLC rather than using a serial chip? Many companies make VLSI chips 
that implement HDLC, from simple serial chips to complicated protocol chips that interpret the 
address and control fields. Like the Tl framer chips, HDLC chips are usually quite complex to 
configure, sometimes even including scatter/gather DMA. Transporting unreliable datagrams 
between routers requires only the most basic aspects of HDLC; the rest gets in the way. 

Why programmed I/O rather than DMA? There was no room on the printed circuit board. A 
DMA, interface to the TurboChannel I/O bus uses lots of ICs to avoid a few extra kernel cycles 
copying data between CPU and adapter, but still requires an interrupt per packet. To get the full 
benefit, DMA must be coupled with main memory buffer management so that the CPU does not 
take an interrupt for each packet. This requires even more ICs and there simply wasn't room. 
Tightly packing surface mount ICs on two stacked PC boards might have done it, but it would 
have taken much longer to design and been much more complicated to use. 
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Why 32-bit CRC rather than 16-bit CRC? The error detecting ability of a 16-bit CRC 
decreases beyond a packet size of about 4K bits; the maximum packet size of this adapter is 16K 
bits. Ethernet, which has a maximum packet size of about 12K bits, uses a 32-bit CRC recom- 
mended in HDLC [19]. This adapter uses the same CRC because packets moving through the 
adapter probably come from or are destined for an Ethernet, so they should get the same level of 
protection. 

Instead of hand-crafting D4 framing and HDLC using a few simple FSMs, a Tl adapter could 
be designed using a Tl framer chip connected to an HDLC chip which DMAed into an on-board 
buffer ram, similar to the design of DEC's PMAD-AA Ethernet adapter. Such a design would 
not require understanding the details of Tl or HDLC. It would certainly be more complex to 
program and there would be more ways to lose performance, but it is a workable approach. 

10. Bugs 

If the last five bits of the CRC were ones, then the TxFSM failed to insert a stuff bit. The 
receiver took the first bit of the ending flag as a stuff bit, and things went downhill from there. 
This turns out to be a common error in HDLC implementations; several standards documents 
mention that a stuff bit may be required after the last CRC bit and before the closing flag. One 
extra state was added to the TxFSM to fix this bug. IP protocols managed to work despite the 
fact that about 3 percent of the packets were being discarded due to bad receiver status. 

The receiver's frame synchronizer would falsely lock onto the transmitter's HDLC flag pat- 
tern 25 percent of the time. If a zero bit in an HDLC flag was picked as a possible frame bit, 
then on an idle link with all flags, every 193rd bit after that would also be a zero, the FrameRom 
would say Maybe 40 times, and frame synchronization would be falsely declared. Simulations 
of the frame sync algorithm used random data and did not find this problem. A two-line change 
to the RxFSM fixed this bug. 

The TurboChannel clock is used to clock the FSMs in the adapter. For a maximum- speed 25 
MHz TurboChannel, the clock is divided by two giving an 80 ns period, or about eight cycles per 
Tl bit. For a minimum-speed 12.5 Mhz TurboChannel, dividing by two results in four cycles 
per bit, which is not enough. The clock division is done in a PAL, so the quick fix is to use a 
different PAL for fast and slow systems; the long-term fix is to make this a CSR bit. 

Several companies make routers that use Tl lines and it would be good if they could inter- 
operate with this adapter. They use HDLC chips (such as the 8530) through a V.35 interface to a 
DSU/CSU which handles framing and clocking. Most HDLC chips only implement 16-bit 
CRCs. The CRC chips used in this design were advertised to implement both 16- and 32-bit 
polynomials, but 16-bit polynomial checking only works if the CRC bits are inverted before be- 
ing shifted into the chip (it does the right thing for 32 bits). By reprogramming PROMs to 
invoke hidden features, the adapter can be made to generate packets with correct 16-bit CRCs, 
but it can't check the 16-bit CRC of an incoming packet (software can do it fairly inexpensively). 

HDLC shifts data least significant bit first, but the adapter shifted out the most significant bit 
first. The order was reversed by reprogramming the transmitter and receiver shift register PALs, 
but the receiver CRC input was hard-wired to the wrong end of the SR. A printed circuit trace 
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had to be cut and a wire added; the adapter talked to itself or others of its kind just fine the old 
way. 

The RxFSM was generating FIFO write pulses when the FIFO was full. The data sheet im- 
plied that this was harmless, but by pounding on the adapter for about six hours in a particular 
way, the FIFO could be driven into a bad state. Fifo Write was already passing through a PAL 
for other reasons, so it was simple to quash it if FifoFull was true; this required adding a wire 
from FifoFull to an unused input on the PAL. The FifoOverflow logic had to be reprogrammed 
as a side effect. 
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